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A.  The  Representation  of  SCHEME  Procedures  as  S-expresslons 


For  those  who  like  this  sort  of  thing,  here  is  the  BNF  for  SCHEME 
programs  {Note  LISP  BNF} : 


<form>  (non-symbol  atom)  | (Identlf 1er>  | (magic)  | (combination) 
(Identifier)  (atomic  symbol) 

(magic)  (lambda-expression) 

I (QUOTE  (s -expression)  ) 

( (IF  (form)  (form)  (form)  ) 

( (IF  (form)  (Form)  ) 

I (LABELS  ( (labels  list)  ) (body)  ) 

I (OEFIHE  (identifier)  (lambda-expression)  ) 

I (OEFIHE  (Identifier)  ( (Identifier  list)  ) (form)  ) 

I (DEFINE  ( (Identifier)  (Identifier  list)  ) (form)  ) 

I (ASET1  (Identifier)  (form)  ) 

I (FlUIDBIND  ( (fluldblnd  list)  ) (form)  ) 

I (FLUID  (Identifier)  ) 

I (FLUIDSET1  (identifier)  (form)  ) 

I (CATCH  (identifier)  (form)  ) 

I (syntactic  extension) 

(lambda-expression)  (LAMBOA  ( (Identifier  list)  ) (body)) 
(identifier  list)  (empty)  | (Identifier)  (Identifier  list) 

(body)  : :«  (form) 

(labels  list)  (empty) 

I ( (Identifier)  (lambda-expression)  ) (labels  list) 
(fluldblnd  list)  : (empty)  | ( (Identifier)  (form)  ) (fluldblnd  list) 
(combination)  ( (form  list)  ) 

(form  list)  (form)  | (form)  (form  list) 

(syntactic  extension)  ( (magic  word)  . (s-expresslon)  ) 

(magic  word)  (atomic  symbol) 

(non-symbol  atom)  (number)  | (array)  | (string)  | ... 


Atoms  which  are  not  atomic  symbols  (identifiers)  evaluate  to 
themselves.  Typical  examples  of^hjrJi^atoms^arp^fiumbepf,  -arrays  jTfcHF  lAtags 
(character  arrays).  , Symbols  ariftrpited  as  lddhtif ier**  oV  varMlts.  ^They 


may  be  lexically  bound  by  lambda-expressions.  There  is  a global  environment 
containing  values  for  (some)  free  variables.  Many  of  the  variables  in  this 
global  environment  initially  have  as  their  values  primitive  operations  such 
as,  for  example,  car,  cons,  and  plus.  SCHEME  differs  from  most  LISP  systems  in 
that  the  atom  car  i$  not  itself  an  operation  (in  the  sense  of  being  an 
invocable  object,  e.g.  a valid  first  argument  to  apply),  but  only  has  one  as  a 
value  when  considered  as  an  identifier. 

Non-atomic  forms  are  divided  by  the  evaluator  into  two  classes: 
combinations  and  "magic  (special)  forms".  The  BNF  given  above  is  ambiguous; 
any  magic  form  can  also  be  parsed  as  a combination.  The  evaluator  always 
treats  an  ambiguous  case  as  a magic  form.  Magic  forms  are  recognized  by  the 
presence  of  a "magic  (reserved)  word”  in  the  car  position  of  the  form.  All 
non-atomic  forms  which  are  not  magic  forms  are  considered  to  be  combinations. 
The  system  has  a small  initial  set  of  magic  words;  there  ijs  also  a mechanism 
for  creating  new  ones  (Note  FUNCALL  is  a Pain). 

A combination  is  considered  to  be  a list  of  subforms.  These  subforms 
are  all  evaluated.  The  first  value  must  be  a procedure;  it  is  applied  to  the 
other  values  to  get  the  value  of  the  combination.  There  are  four  Important 
points  here: 

(1)  The  procedure  position  is  always  evaluated  just  like  any  other 
position.  (This  is  why  the  primitive  operators  are  the  values  of  global 
identifiers.) 

(2)  The  procedure  is  never  "re-evaluated";  if  the  first  subform  fails  to 
evaluate  to  an  applicable  procedure,  it  is  an  error.  Thus,  unlike  most 
LISP  systems,  SCHEME  always  evaluates  the  first  subform  of  a combination 
exactly  once. 

(3)  The  arguments  are  all  completely  evaluated  before  the  procedure  is 
applied;  that  is,  SCHEME,  like  most  LISP  systems,  is  an  applicative-order 
language.  Many  SCHEME  programs  exploit  this  fact. 

(4)  The  argument  form:,  (and  procedure  form)  may  in  principle  be  evaluated 
in  any  order.  This  is  unlike  the  usual  LISP  left-to-rlght  order.  (All 
SCHEME  Interpreters  implemented  so  far  have  in  fact  performed  left-to-right 
evaluation,  but  we  do  not  wish  programs  to  depend  on  this  fact.  Indeed, 
there  are  some  reasons  why  a clever  interpreter  might  want  to  evaluate  them 
right-to-left,  e.g.  to  get  things  on  a stack  in  the  correct  order.) 
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B.  Catalogue  of  Magic  Forms 


B.I.  Kernel  Magic  Forms 


The  magic  forms  in  this  section  are  all  part  of  the  kernel  of  SCHEME, 
and  so  must  exist  in  any  SCHEME  implementation. 


(LAMBDA  ( 'Identifier  11*t>  > <body>  ) 

Lambda-expressions  evaluate  to  procedures.  Unlike  most  LISP 
systems,  SCHEME  does  not  consider  a lambda-expression  (an  s-expression 
whose  car  is  the  atom  lambda)  to  be  a procedure.  A lambda-expression  only 
evaluates  to  a procedure.  A lambda-expression  should  be  thought  of  as  a 
partial  description  of  a procedure;  a procedure  and  a description  of  it 
are  conceptually  distinct  objects.  A lambda-expression  must  be  "closed* 
(associated  with  an  environment)  to  produce  a procedure  object.  Evaluation 
of  a lambda-expression  performs  such  a closure  operation. 

The  resulting  procedure  takes  as  many  arguments  as  there  are 
identifiers  in  the  identifier  list  of  the  lambda-expression.  When  the 
procedure  is  eventually  invoked,  the  intuitive  effect  is  that  the 
evaluation  of  the  procedure  call  is  equivalent  to  the  evaluation  of  the 
<body>  in  an  environment  consisting  of  (a)  the  environment  in  which  the 
lambda-expression  had  been  evaluated  to  produce  the  procedure,  plus  (b)  the 
pairing  of  the  identifiers  of  the  <id»ntifiar  n*t>  with  the  arguments 
supplied  to  the  procedure.  The  pairings  (b)  take  precedence  over  the 
environment  (a),  and  to  prevent  confusion  no  identifier  may  appear  twice  in 
the  n*t>.  The  net  effect  is  to  Implement  ALGOL-style  lexical 

scoping  [Naur],  and  to  "solve  the  funarg  problem"  [Hoses]. 


(IF  <pred1cate>  <consequent>  (alternative)) 

This  is  a primitive  conditional  operator.  The  predicate  form  is 
evaluated.  If  the  result  is  non-Ni*.  (Note  if  Is  Data-Dependent) , then  the 
consequent  is  evaluated,  and  otherwise  the  alternative  is  evaluated.  The 
resulting  value  (if  there  is  one)  is  the  value  of  the  if  form. 


(IF  (predicate)  (coniequent) ) 

As  above,  but  if  the  predicate  evaluates  to  nil,  then  nil  is  the 
value  of  the  if  form.  (As  a matter  of  style,  this  is  usually  used  only 
when  the  value  of  the  if  form  doesn't  matter,  for  example,  when  the 
consequent  is  Intended  to  cause  a side  effect.) 
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(QUOTE  <s-expr«s*1on>) 

As  in  LISP,  this  quotes  the  argument  form  so  that  it  will  be  passed 
verbatim  as  data;  the  value  of  this  form  is  <*-«xpr«*sion>.  If  a SCHEME 
implementation  has  the  NacLISP  read-macro-character  feature,  then  the 
abbreviation  *foo  may  be  used  instead  of  (quote  foo). 


(LABELS  ( < label*  11*t>  ) <body>  ) 

Where  <1abal*  11*t>  <empty>  | ( <1d*nt1f1*r>  <1ambda-*xpr***1on>  ) <lab*l*  11*t> 

This  has  the  effect  of  evaluating  the  <body>  in  an  environment  where 
all  the  Identifiers  (which,  as  for  lambda,  must  all  be  distinct)  in  the 
labels  list  evaluate  to  the  values  of  the  respective  lambda-expressions. 
Furthermore,  the  procedures  which  are  the  values  of  the  lambda-expressions 
are  themselves  closed  in  that  environment,  and  not  in  the  outer 
environment;  this  allows  the  procedures  to  call  themselves  and  each  other 
recursively.  For  example,  consider  a procedure  which  counts  all  the  atoms 
in  a list  structure  recursively  to  all  levels,  but  which  doesn’t  count  the 
nils  which  terminate  lists  (but  nils  in  the  car  of  a list  count).  In  order 
to  perform  this  we  define  two  mutually  recursive  procedures,  one  to  count 
the  car  and  one  to  count  the  cdr,.  as  follows: 

(DEFINE  COUNT 

(LAMBDA  (L) 

(LABELS  ((COUNTCAR 

(LAMBDA  (L) 

(IF  (ATOM  L)  1 

(+  (COUNTCAR  (CAR  L)) 

(COUNTCDR  (CDR  L )))))) 

(COUNTCDR 
(LAMBOA  (L) 

(IF  (ATOM  L) 

(IF  (NULL  L)  0 1) 

(♦  (COUNTCAR  (CAR  L)) 

(COUNTCOR  (CDR  L ))))))) 

(COUNTCOR  L)))) 

(We  have  decided  not  to  use  the  traditional  LISP  label  primitive  in 
SCHEME  because  it  is  difficult  to  define  several  mutually  recursive 
procedures  using  only  label.  Although  labels  is  a little  more  complicated 
than  label,  it  is  considerably  more  convenient.  Contrast  this  design 
decision  with  the  choice  of  if  over  the  more  traditional  cond,  where  the 
definitional  simplicity  of  if  outweighed  the  somewhat  greater  convenience 

of  COND.) 
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B.2.  Side  Effects 


These  magic  forms  produce  side  effects  in  the  environment. 


(DEFINE  < Identifier)  Owtbde-expreulon)  ) 

This  is  used  for  defining  a procedure  in  the  "global  environment" 
permanently,  as  opposed  to  labels,  which  is  used  for  temporary  procedure 
definitions  in  a local  environment,  oefine  takes  a name  and  a lambda- 
expression;  it  evaluates  the  lambda-expression  in  the  global  environment 
and  causes  the' result  to  be  the  global  value  of  the  identifier,  (define  may 
perform  other  implementation-dependent  operations  as  well,  such  as  keeping 
track  of  defined  procedures  for  an  editor.  For  this  reason  it  is  the 
preferred  way  to  define  a globally  available  procedure.) 


(DEFINE  identifier)  ( identifier  11*t>  ) <form  11»t>  ) 

(OEFINE  ( identifier)  identifier  lilt)  ) <fone  11*t>  ) 

These  alternative  syntaxes  permitted  by  define  are  equivalent  to: 

(DEFINE  identifier) 

( LAMBDA  ( identifier  list)  ) 

(BLOCK  <form  Hit)  ))) 

where  block  is  a syntactic  extension  defined  below.  For  example,  these 
three  definitions  are  equivalent: 

(DEFINE  CIRCULATE  (LAMBDA  (X)  (RPLACO  X X))) 

(DEFINE  CIRCULATE  (X)  (RPLACO  X X)) 

(DEFINE  (CIRCULATE  X)  (RPLACO  X X)) 

These  forms  are  provided  to  support  stylistic  diversity. 


(ASET'  identifier)  <form>) 

This  is  analogous  to  the  LISP  primitive  setq.  For  example,  to 
define  a cell  [Smith  and  Hewitt],  we  may  use  aset'  as  follows: 


/ 

I 





(DEFINE  CONS -CEIL 

(LAMBDA  (CONTENTS) 

(LABELS  ((THE -CELL 

(LAMBDA  (MSG) 


(IF  (EQ  MSG  'CONTENTS?)  CONTENTS 
(IF  (EQ  MSG  'CELL?)  'YES 
(IF  (EQ  (CAR  MSG)  '<-) 

(BLOCK  (ASET'  CONTENTS  (CADR  MS6) ) 
THE-CELL) 

(ERROR  '(UNRECOGNIZED  MESSAGE  - CELL | 
MSG 

' VRN6-TYPE-ARG ))))))) 


THE-CELL))) 


Note  that  aset'  may  be  used  on  global  identifiers  as  well  as  locally  bound 
identifiers  (Note  aset  Has  Disappeared). 


B.3.  Dynamic  Magic 


These  magic  forms  implement  escape  objects  and  fluid  (dynamic) 
variables.  They  are  not  a part  of  the  essential  kernel.  For  a further 
explication  of  their  semantics  in  terms  of  kernel  primitives,  see 
[Imperative]. 


( FLU1DBIN0  ( <f luldblnd  1.1*t>  ) <form>  ) 

Where  <fluldb1nd  H»t>  <«mpty>  ( ( <1d«nt1f1«r>  <fonn>  ) <f luldblnd  T1*t> 


This  evaluates  the  <ron»>  in  the  environment  of  the  fluidbind  form, 
with  a dynamic  environment  to  which  dynamic  bindings  of  the  identifiers  in 
the  <f luldblnd  n*t>  have  been  added.  Any  procedure  dynamically  called  by  the 
form,  even  if  not  lexically  apparent  to  the  fluidbind  form,  will  see  this 
dynamic  environment  (unless  modifiod  by  further  fluidbinds,  of  course).  The 
dynamic  environment  is  restored  on  return  from  the  form. 

Most  LISP  systems  use  a dynamic  environment  fGr  all  variables.  A 
SCHEME  which  implements  fluidbind  provides  two  distinct  environments.  The 
fluid  variable  named  foo  Is  completely  unrelated  to  a normal  lexical 
variable  named  foo  (Note  Global  Fluid  Environment),  and  the  access 
mechanisms  for  the  two  are  distinct. 


(FLUID  Odentlf  1<tr>  ) 


The  value  of  this  form  is  tlu  value  of  the  <id«ntin«r>  in  the 
current  dynamic  environment.  In  SCHEME  implementations  which  have  the 
MacLISP  read-macro-character  feature,  (fluid  foo)  may  be  abbreviated  to  *foo. 
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(FLUIDSET'  <1 dentlf 1er>  <form>  ) 

The  value  of  the  <form>  is  assigned  to  the  <identuier>  in  the  current 
dynamic  environment. 


(STATIC  <1dent1f 1er>) 

The  value  of  this  is  the  value  of  the  lexical  identifier;  writing 
this  is  the  same  as  writing  just  <identirier>  (Note  What  Good  Is  It?}. 


(CATCH  <1dent1f  1er>  <form>  ) 

This  evaluates  the  form  in  an  environment  where  the  identifier  is 
bound  to  an  "escape  object"  [Landin]  [Reynolds].  This  is  a strange  object 
which  can  be  invoked  as  if  it  were  a procedure  of  one  argument.  When  the 
escape  object  is  so  invoked,  then  control  proceeds  as  if  the  catch 
expression  had  returned  with  the  supplied  argument  as  its  value  {Note 
Multiple  Throw}. 

If  both  catch  and  fluidbind  are  implemented,  then  their  semantics  are 
intertwined.  When  the  escape  object  is  called,  then  the  dynamic 
environment  is  restored  to  the  one  which  was  current  at  the  time  the  catch 
form  was  evaluated  {Note  Environment  Symmetry}. 

For  a contorted  example,  consider  the  following  obscure  definition 
of  sort  (Sussman's  least  favorite  style/Steele's  favorite;  but  see 
[SCHEME]): 

(DEFINE  SORT 

(LAMBDA  (X  EPSILON) 

((LAMBDA  (ANS  TAG  GO) 

(CATCH  RETURN 
(BLOCK 

(CATCH  M (ASET’  TAG  M))  iCREATE  PROG  TAG 

(IF  (<  (ABS  (-$  (»$  ANS  ANS)  X))  EPSILON)  ;CAMGE 
(RETURN  ANS))  ;POPJ 

(ASET*  ANS  (//$  (♦$  (//$  X ANS)  ANS)  2.0))  ;MOVEM 
(GO  TAG))))  ;0RST 


(LAMBDA  (F)  (F  NIL))))) 

This  example  differs  slightly  from  the  version  given  in  [SCHEME];  notice 
the  forms  (return  ans)  and  (go  tag). 

As  another  example,  we  can  define  a throw  function,  which  may  then 
be  used  with  catch  much  as  it  is  in  MacLISP  [Moon]  (except  that  in  MactISP 
the  tag  is  written  after  the  body  of  the  catch,  not  before): 


(DEFINE  THROW  (LAMBOA  (TAG  RESULT)  (TAG  RESULT))) 

An  example  of  its  use' 

(CATCH  LOSE 

(MAPCAR  (LAMBOA  (X)  (IF  (MINUSP  X)  (THROW  LOSE  NIL)  (SORT  X))) 

NUMLIST)) 

Indeed,  note  the  similarity  between  throw  and  the  definition  of  go  in  the 
first  example. 


\ 
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ltactic  Extensions 


SCHEME  has  a syntactic  extension  mechanism  which  provides  a way  to 
define  an  identifier  to  be  a magic  word,  and  to  associate  a function  with  that 
word.  The  function  accepts  the  magic  form  as  an  argument,,  and  produces  a new 
form;  this  new  form  is  then  evaluated  in  place  of  the  original  (magic)  form. 
This  is  precisely  the  same  as  the  MacLISP  macro  facility. 


Some  standard  syntactic  extensions  are  provided  by  the  system  for 
convenience  in  ordinary  programring.  They  are  distinguished  from  other  magic 
words  in  that  they  are  semantically  defined  in  terms  of  others  rather  than 
being  primitive  (Note  FEXPRs  Are  Okay  by  Us).  For  expository  purposes  they 
are  described  here  in  a pattern-matching/production-rule  kind  of  language. 
The  matching  is  on  s-expression  structure,  not  on  character  string  syntax,  and 
takes  advantage  of  the  definition  of  list  notation:  (tie) 

(a  . (b  . (c  . nil))).  Thus  the  pattern  (x  . r)  matches  (A  b c),  witn  x • a and 
r ■ (B  c).  The  ordering  of  the  "productions"  is  significant;  the  first  one 
which  matches  is  to  be  used. 


(BLOCK  x j x ^ ...  xn) 

(BLOCK  x)  -»  x 

(BLOCK  x . r)  -»  ((LAMBDA  (A  B)  (B))  x (LAMBDA  ()  (BLOCK  . r ) ) ) 

block  sequentially  evaluates  the  subfon,<s  x1  from  left  to  right.  For 
example : 

(BLOCK  (ASET'  X A3)  (PRINT  X)  (♦  X 1)) 

returns  after  setting  x to  «3  and  then  printing  it  (Note  block  Exploits 
Applicative  Order). 


(LET  (<Vj  Xj)  (w2  x 2 ) ...  (vn  xn))  . body) 

-»  ((LAMBDA  (Vj  Vj  : . . vn)  (BLOCK  . body))  Xj  x?  ...  xR) 

let  provides  a convenient  syntax  for  binding  several  variables  to 
corresponding  quantities.  It  allows  the  forms  for  the  quantities  to  appear 
textually  adjacent  to  their  corresponding  variables.  Notice  that  the 
variables  are  all  bound  simultaneously,  not  sequentially,  and  that  the 
initialization  forms  x1  may  be  evaluated  in  any  order.  For  convenience, 
let  also  supplies  a block  around  the  forms  constituting  Its  body. 


Steele  and  Sujsmin 


rt  on  SCHEME 


(DO  ((vj  Xj  ij)  ...  (vn  xn  sn))  (teat  . done)  . body) 

-»  (LET  ((Al  (LAMBDA  ()  Xj)) 

(61  (LAMBDA  (Vj  ...  vn>  *j)) 


(An  (LAMBOA  ()  xj) 


(Bn  (LAMBDA  (Vj  ...  vn)  *„)) 

(TS  (LAMBOA  (Vj  ...  vj  teit)) 

(DN  (LAMBOA  (Vj  ...  yj  (BLOCK  . do 
(BD  (LAMBDA  (Vj  ...  vn>  (BLOCK  . bo 
(LABELS  ((LOOP 

(LAMBOA  (Z1  ...  Zn) 

(IF  (TS  Z1  ...  Zn) 
(DN  Z1  ...  Zn) 
(BLOCK  (BO  Z1 


done))) 

body)))) 


(LOOP  (81  Z1 


(Bn  Z1  ...  Zn))))))) 


(LOOP  (Al)  ...  (An)))) 


This  is  essentially  the  MacLISP  "new-style"  do  loop  [Moon].  The  variables 
v.  are  bound  to  the  values  of  the  corresponding  x1 , and  stepped  in  parallel 
after  every  execution  of  the  body  by  the  *1  (by  "step"  we  mean  "set  to  the 
value  of",  not  "increment  by").  If  an  *1  is  omitted,  vi  is  assumed;  this 
results  in  the  variable  not  being  stepped.  If  in  addition  x1  is  omitted, 
nil  is  assumed.  The  loop  terminates  when  the  test  evaluates  non-NiL;  it  is 
evaluated  before  each  execution  of  the  body.  When  this  occurs,  the  done 
part  is  evaluated  as  a block. 

The  complexity  of  the  definition  shown  is  due  to  an  effort  to  avoid 
conflict  of  variable  names,  as  for  block.  The  auxiliary  variables  ai,  bi, 
and  zi  must  be  generated  to  produce  as  many  as  are  needed,  but  they  need 
not  be  chosen  different  from  all  variables  appearing  in  *1t  iif  body,  etc. 

The  iteration  is  effected  entirely  by  procedure  calls.  In  this 
manner  the  definition  of  do  exploits  the  tail-recursive  properties  of 
SCHEME  [SCHEME]  [Imperative]. 

As  an  example,  here  is  a definition  of  a function  to  find  the 
length  of  a list: 


(DEFINE  (LENGTH  X) 

(DO  ((Z  X (COR  Z)) 

(N  0 (+  N 1))) 

((NULL  Z)  N))) 

The  initializations  forms  x1  may  be  evaluated  in  any  order,  and  on 
each  iteration  the  stepping  form  may  be  evaluated  in  any  order.  This 
differs  from  the  MacLISP  definition  of  do.  For  example,  this  definition  of 
nreverse  (destructively  reverse  a list)  would  work  in  MacLISP  but  not 
necessarily  in  SCHEME: 


(DEFINE  (LOOKUP  NAME  VARS  VALUES) 

(ITERATE  MAJOR-LOOP 

((VARS -BACKBONE  VARS) 

(VALUES-BACKBONE  VALUES)) 

(IF  (NULL  VARS-BACKBONE) 

NIL 

(ITERATE  MINOR-LOOP 

((VARS-RIB  (CAR  VARS-BACKBONE)) 

(VALUES-RIB  (CAR  VALUES-BACKBONE))) 

(IF  (NULL  VARS-RIB) 

(MAJOR-LOOP  (COR  VARS-BACKBONE) 

(CDR  VALUES-BACKBONE)) 

(IF  (EQ  (CAR  VARS-RIB)  NAME) 

VALUES-RIB 

(MINOR-LOOP  (CDR  VARS-RIB) 

(COR  VALUES-RIB)))))))) 

(We  had  originally  wanted  to  call  this  construct  loop,  but  see 
(Note  funcall  is  a Pain}.  Compare  this  with  looping  constructs  appearing  in 
[Hewitt].) 

It  happens  that  iterate  is  a misleading  name;  the  construct  can 
actually  be  used  for  recursion  ("true"  recursion,  as  opposed  to  tail- 
recursion)  as  well.  If  the  name  is  invoked  from  a non-tail-recursive 
situation,  the  argument  evaluation  in  which  the  call  is  embedded  is  not 
aborted.  It  just  so  happens  that  we  have  found  iterate  useful  primarily  to 
implement  complicated  iterations.  One  can  draw  the  rough  analogy  iterate  : 
LABELS  : : LET  : LAMBDA. 


(TEST  pred  fn  alt) 

-»  ((LAMBDA  (P  F A)  ( IF  P ((F)  P)  (A))) 
pred 

I ( LAMBDA  ()fn) 

(LAMBDA  ()  alt)) 

The  predicate  is  evaluated;  if  its  value  is  non-NiL  then  the  form  fn 
should  evaluate  to  a procedure  of  one  argument,  which  is  then  invoked  on 
the  value  of  the  predicate.  Otherwise  the  alternative  alt  is  evaluated. 

This  construct  is  • of  occasional  use  with  LISP  "predicates"  which 
return  a "useful"  non-NiL  value.  For  the  consequent  of  an  if  to  get  at  the 
non-Nit  value  of  the  predicate,  one  might  first  *»ind  a variable  to  the 

I value  of  the  predicate,  and  this  variable  would  then  be  visible  to  the 

alternative  as  well.  With  test,  the  use  of  the  variable  is  restricted  to 
the  consequent. 

An  example: 

(TEST  (ASSO  VARIABLE  ENVIRONMENT) 


(CONO)  -*  'MIL 

(qONO  (p)  . r)  -♦  ( ( LAMBDA  (V  R)  (IF  VV  («))) 

P 

(LAMBDA  ()  (COMO  . r))) 

(COND  (p  •>  f)  . r)  -»  (TEST  p f (COMO  . r)) 

(COND  (p  . e)  . r)  -»  (IF  p (BLOCK  . «)  (COMO  . p) ) 


This  cond  is  a superset  of  the  FlacLISP  cond.  As  in  FlacLISP  singleton 
clauses  return  the  value  of  the  predicate  if  it  is  non-NiL,  and  clauses 
with  two  or  more  forms  treat  the  first  as  the  predicate  and  the  rest  as 
constituents  of  a block,  thus  evaluating  them  in  order. 

The  extension  to  the  FlacLISP  cond  made  in  SCHEFIE  is  flagged  by  the 
atom  ->.  (It  cannot  be  confused  with  the  more  general  case  of  two  block 
constituents  because  having  the  atom  ■>  as  the  first  element  of  a block  is 
not  useful.)  In  this  situation  the  form  r following  the  ■>  should  have  as 
its  value,  a function  of  one  argument;  if  the  predicate  p is  non-NiL,  this 
function  is  determined  and  invoked  on  the  value  returned  by  the  predicate. 
This  is  useful  fcr  the  common  situation  encountered  in  LISP: 

(COND  ((SETO  IT  (GET  X ’PROPERTY))  (HACK  IT)) 

which  in  SCHEFIE  can  be  rendered  without  using  a variable  global  to  the 

cond: 

(COND  ((GET  X ’PROPERTY) 

«>  (LAMBDA  (IT)  (HACK  IT))) 

...) 

or,  in  this  specific  instance,  simply  as: 

(COND  ((GET  X ’PROPERTY)  ■>  HACK) 

•••) 
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(0«  «,  *J  ...  *n> 

(OR)  -♦  'RIL 
(OR  x)  — » x 

(OR  x . r)  -♦  (CORO  (x)  (T  (OR  . r))) 

This  standard  LISP  primitive  evaluates  the  forms  in  order,  returning  the 
first  non-RiL  value  (and  ignoring  all  following  forms).  If  all  forms 
produce  ril,  then  ril  is  returned  (Note  Tail-Recursive  or). 


(AND  Xj  x2  ...  xn) 

(AND)  -»  »T 
(AND  x)  -»  x 

(AND  x . r)  -»  (CONO  (x  (ARO  . r))) 

This  standard  LISP  primitive  evaluates  the  forms  x1  in  order.  . If  any  form 
produces  ril,  then  ril  is  returned,  and  succeeding  forms  x1  are  ignored.  If 
all  forms  produce  non-RU  values,  the  value  of  the  last  is  returned  (Note 
Tail-Recursive  arb). 


( AMAPCAR  f Xj  x2  ...  xn) 

-*  (00  ( (FN  F) 

(VI  Xj  (COR  VI ) ) 

(V2  x2  (COR  V2) ) 

(Vn  xn  (COR  Vn)) 

(0  'RIL  (CONS  (FN  (CAR  VI)  (CAR  V2)  ...  (CAR  Vn))  0))) 

((OR  (NULL  VI)  (NULL  V2)  ...  (NULL  Vn)) 

( NREVERSE  Q))) 

amapcar  is  analogous  to  the  NacLISP  mapcar  function.  The  function  r,  a 
function  of  n arguments,  is  mapped  simultaneously  down  the  lists  Xj,  *2, 
...,  xn;  that  is,  r is  applied  to  tuples  of  successive  elements  of  the 
lists.  The  values  returned  by  r are  collected  and  returned  as  a list. 
Note  that  amapcar  of  a fixed  number  of  arguments  could  easily  be  written  as 
a function  in  SCHEME.  It  is  a syntactic  extension  only  so  that  it  may 
accommodate  any  number  of  arguments,  which  saves  the  trouble  of  defining  an 
entire  set  of  primitive  functions  amapcari,  amapcar2,  ...  where  amapcarr  takes 
n+i  arguments. 
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-*  (DO  ((FN  f) 


(VI  kx  (COR  VI)) 

( V2  x2  (COR  V2)) 

(Vn  xn  (COR  Vn)) 

(0  'NIL  (CONS  (FN  VI  V2  ...  Vn)  0))) 

((OR  (NUU  VI)  (NULL  V2)  ...  (NULL  Vn)) 

(NREVERSE  0))) 

amaplist  is  analogous  to  the  MaclISP  haplist  function.  The  function  t,  a 
function  of  n arguments,  is  applied  to  tuples  of  successive  tails  of  the 
lists.  The  values  returned  by  f are  collected  and  returned  as  a list. 


(AMAPC  f x,  x,  ...  x_ ) 
i £ n 

-»  (DO  ((FN  f) 

(XI  Xj  (COR  XI)) 

<X2  x2  (COR  X2 ) ) 

(Xn  xn  (COR  Xn))) 

((OR  (NULL  XI)  (NULL  X2)  ...  (NULL  Xn)) 

•NIL) 

(FN  (CAR  XI)  (CAR  X2)  ...  (CAR  Xn))) 

amapc  is  analogous  to  the  MacLISP  mapc  function.  The  procedure  f,  a 
procedure  taking  n arguments,  is  mapped  simultaneously  down  the  lists  Xj, 

x2 xn;  that  is,  r is  applied  to  tuples  of  successive  elements  of  the 

lists.  Thus  amapc  is  similar  to  amapcar,  except  that  no  values  are  expected 
from  f;  therefore  r.  need  not  be  a function,  but  may  be  any  procedure. 


(PROG  varllst  *j  *2  ...  »n) 

The  SCHEME  prog  is  like  the  ordinary  LISP  prog.  There  is  no  simple 
way  to  describe  the  transformation  of  prog  syntax  into  SCHEME  primitives. 
The  basic  idea  is  that  a large  labels  statement  is  created,  with  a labelled 
procedure  (of  zero  arguments)  for  each  prog  statement.  Each  statement  is 
transformed  in  such  a way  that  each  one  that  "drops  through"  is  made  to 
call  the  labelled  procedure  for  the  succeeding  statement;  each  appearance 
of  (go  tag)  is  converted  to  a call  on  the  labelled  procedure  for  the 
statement  following  the  tag;  and  each  appearance  of  (return  vaiva)  is 
replaced  by  vaiua. 

Practical  experience  with  SCHEME  has  shown  that  prog  is  almost 
never  used.  It  1$  usually  more  convenient  just  to  write  the  corresponding 
labels  directly.  This  allows  one  to  write  labels  procedures  which  take 


arguments,  which  tends  to  clarify  the  flow  of  data  [Imperative]. 


The  rest  of  this  section  (FSUBRs)  applies  only  to  the  POP*  10  HacLISP 
implementation  of  SCHEHE. 


FSUBRs 

As  a user  convenience,  the  PDP-10  HacLISP  implementation  of  SCHEHE 
treats  FSUBRs  specially;  any  FSUBR  provided  by  the  HacLISP  system  is 
automatically  a SCHEHE  primitive  (but  user  FSUBRs  are  not).  Of  course,  if 
the  FSUBR  tries  to  evaluate  some  form  obtained  from  its  argument,  the 
variable  references  will  not  refer  to  SCHEHE  variables.  As  a special  case, 
the  SCHEHE  syntactic  extension  aarraycall  is  provided  to  get  the  effect  of 
the  HacLISP  FSUBR  arraycall. 


C.2.  User-Provided  Extensions 

A SCHEHE  implementation  should  have  one  or  more  ways  for  the  user  to 
extend  the  inventory  of  magic  words.  The  methods  provided  will  vary  from 
implementation  to  implementation.  The  following  primitive  (schmac)  is  provided 
in  the  PDP-10  HacLISP  implementation  of  SCHEHE. 


(SCHMAC  nam*  pattern  body) 

After  execution  of  this  form,  a syntactic  extension  keyed  on  the 
atom  name  is  defined.  When  a form  (name  . rest)  is  to  be  evaluated,  rest  is 
matched  against  the  pattern,  which  is  a (possibly  "dotted")  list  of 
variables.  The  body  is  then  evaluated  in  an  environment  where  the 

variables  in  the  pattern  have  as  values  the  corresponding  parts  of  rest. 
This  should  result  in  a form  to  be  evaluated  in  place  of  the  form 

(name  . rest). 

The  body  is  not  necessarily  SCHEHE  code,  but  rather  code  in  the 

same  meta-language  used  to  write  the  evaluator.  In  the  PDP-10  HacLISP 

SCHEHE  Implementation,  the  body  is  HacLISP  code. 

As  an  example,  here  is  a definition  of  test: 

(SCHMAC  TEST  (PRED  FH  ALT) 

(LIST  '(LAMBDA  (P  F A)  (IF  P ((F)  P)  (A))) 

PRED 

(LIST  'LAMBDA  '()  FR) 

(LIST  'LAMBDA  ’()  ALT))) 

The  body  of  a SCHMAC  almost  always  performs  a complicated  conslng- 
up  of  a program  structure.  Often  one  needs  to  make  a copy  of  a standard 


St«elt  «nd  Sui».n«n 


structure,  with  a few  values  filled  in.  To  make  this  easier,  SCHEME 
provides  an  "unquoting  quote"  feature.  An  expression  of  the  form  *<»- 
expression)  is  Just  like  • <s-exprtssion>,  except  that  sub-expressions  preceded 
by  "."  or  "•"  represent  expressions  whose  values  are  to  be  made  part  of  (a 
copy  of)  the  s-expresslon  at  that  point.  A ".*  denotes  simple  inclusion, 
while  "•"  denotes  "splicing"  or  "segment"  inclusion.  (Compare  this  with 
the  treatment  of  lists  with  embedded  forms  in  MUDDLE  [Galley  and  Pfister], 
which  in  turn  Inspired  the  t*  syntax  of  CONNIVER  [McDermott  and  Sussman], 
from  which  SCHEME'S  • syntax  is  derived.)  Using  this,  one  can  define  test 
as  follows: 


(SCHMAC  TEST  (PRED  FN  ALT) 

•((LAMBOA  (p  f A)  (IF  P ((F)  P)  (A))) 
.PRED 

(LAMBDA  ()  ,FN) 

(LAMBDA  ()  .ALT))) 


Similarly,  let  can  be  defined  as 


(SCHMAC  LET  (DEFNS  . BODY) 

“((LAMBDA  .(MAPCAR  'CAR  DEFNS) 
(BLOCK  . .BODY)) 
•(MAPCAR  ’CADR  DEFNS))) 


One  could  also  write  (block  ibody)  Instead  of  (block  . .body). 

Notice  the  use  of  (mapcar  'car  defns)  rather  than  (amapcar  car  defns) 
recall  that,  as  stated  above,  the  body  of  a schmac  is  MacLISP  code, 
SCHEME  code.  Consider  too  this  definition  of  cond: 


(SCHMAC  COND  CLAUSES 

(COND  ((NULL  CLAUSES)  "NIL) 

((NULL  (COAR  CLAUSES)) 

' '((LAMBDA  (V  R)  (IF  V V R)) 

, (CAAR  CLAUSES) 

(LAMBOA  ()  (COND  . .(COR  CLAUSES))))) 

<(E0  (CAOAR  CLAUSES)  '■>) 

•(TEST  .(CAAR  CLAUSES)  .(CAODAR  CLAUSES)  (COND 
(T  ’(IF  .(CAAR  CLAUSES) 

(BLOCK  . .(COAR  CLAUSES)) 

(COND  . .(COR  CLAUSES)))))) 


(COR  CLAUSES)))) 


We  have  used  cond  to  define  cond!  The  definition  is  not  circular,  however; 
the  Maclisp  cond  is  being  used  to  define  the  SCHEME  cond,  indeed  the  two 
have  slightly  different  semantics.  The  definition  would  have  been  circular 
had  we  written  (cond  (v)  (r))  instead  of  (IF  v v R),  for  the'  latter  is  part  of 
the  generated  SCHEME  code. 
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(MACRO  n«"i«  pattern  body) 

This  is  just  like  schmac,  except  that  body  is  SCHEME  code  rather 
than  MacLISP  code.  While  macros  defined  with  schmac  run  only  in  a MacLISP 
implementation  of  SCHEME,  those  defined  with  macro  should  be  completely 
transportable.  (We  described  schmac  first  to  emphasize  the  fact  that  macros 
are  conceptually  part  of  the  interpreter,  and  so  conceptually  written  in 
the  meta- language.  It  so  happens,  however,  that  SCHEME  is  a good  meta- 
language for  SCHEME,  and  so  introducing  this  meta-circularity  provides  no 
serious  problems.  Contrast  this  with  writing  PL/I  macros  in  PL/I!) 

The  example  of  defining  coho  using  schmac  above  would  be  circular  if 
we  changed  the  word  schmac  to  macro.  However,  we  can  avoid  this  by  avoiding 
the  use  of  coho  in  the  definition: 

(MACRO  COHO  CLAUSES 

(IF  (HULL  CLAUSES)  "HIL 

(IF  (HULL  (COAR  CLAUSES)) 

"((LAMBDA  (V  R)  (IF  V V R)) 

, (CAAR  CLAUSES) 

(LAMBDA  ()  (COHO  . .(COR  CLAUSES)))) 

(IF  (EQ  (CADAR  CLAUSES)  '■>) 

"(TEST  .(CAAR  CLAUSES) 

.(CADDAR  CLAUSES) 

• (COHO  . ,(C0R  CLAUSES))) 

"(IF  .(CAAR  CLAUSES) 

(BLOCK  . ,(CDAR  CLAUSES)) 

(COHO  . .(COR  CLAUSES))))))) 

We  strongly  encourage  the  use  of  macro  instead  of  schmac  in  practice 
so  that  macro  definitions  will  not  be  dependent  on  the  properties  of  a 
specific  implementation. 
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J.  Primitive  SCHEME  Functions 

All  the  usual  NacLISP  SUBRs  are  available  In  SCHEME  as  procedures 
which  are  the  values  of  global  variables.  The  particular  primitives  cons,  car, 
cor,  atom,  and  eq  are  part  of  the  kernel  of  SCHEME!  Others,  such  as  ♦,  -,  •, 
//,  •,  equal , rplaca,  rplacd,  etc.  are  quite  convenient  to  have. 

Although  there  is  no  way  in  SCHEME  to  write  a LEXPR  (a  function  of  a 
variable  number  of  arguments),  MacLISP  LSUBRs  are  also  available  to  the  SCHEME 
user.  One  may  wish  to  regard  these  as  syntactic  extensions  in  much  the  same 
way  amapcar  is;  for  example,  list  may  be  thought  of  as  a syntactic  extension 
such  that: 


(LIST)  -»  'R1 
(LIST  x . r) 


(CONS  x (LIST  . r)) 


Below  we  also  describe  some  additional  primitive  functions  provided 
with  SCHEME.  Their  names  do  not  have  any  special  syntactic  properties  in  the 
way  that  the  magic  words  for  syntactic  extensions  described  in  the  previous 
section  do.  However,  they  do  deal  with  the  underlying  implementation,  and  so 
could  not  be  programmed  directly  by  the  user  were  they  not  provided  as 
primitives . 


The  following  primitive  functions  (procp  and  enclose)  arm  part  of  the 
kernel  of  SCHEME. 


(PROCP  thing) 

This  is  a predicate  which  is  true  of  procedures,  and  not  of 
anything  else.  Thus  if  (procp  x)  is  true,  then  it  is  safe  to  invoke  the 
value  of  x. 

More  precisely,  if  procp  returns  a non-NiL  value,  then  the  value 
describes  the  number  of  arguments  accepted  by  the  procedure.  For  SCHEME 
procedures  this  will  be  an  integer,  the  number  of  arguments.  For  primitive 
functions,  this  may  be  implementation-dependent;  in  the  PDP-10  MacLISP 
implementation  of  SCHEME,  procp  of  an  LSUBR  returns  the  MacLISP  args 
property  for  that  LSUBR.  If  an  object  given  to  procp  is  a procedure  but 
the  number  of  arguments  it  requires  cannot  be  determined  for  some  reason, 
then  procp  returns  t. 


(ENCLOSE  fnrpp  envrep) 


enclose  takes  two  s-expressions,  one  representing  the  code  for  a 
procedure,  and  the  other  representing  the  (lexical)  environment  in  which 
the  procedure  is  to  run.  enclose  returns  a (closed)  procedure  which  can  be 
invoked. 
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The  representation  of  the  code  is  the  standard  s-expression 
description  (a  lambda-expression).  The  representation  of  the  environment 
is  an  association  list  (a-llst)  of  the  traditional  kind: 

((verl  . veluel)  (var2  . value2)  ...) 

nil  represents  the  global  lexical  environment. 

This  description  of  enclose  should  not  be  construed  as  describing 
how  the  implementation  of  SCHEME  represents  either  environment  or  code 
internally.  Indeed,  enclose  could  be  as  simple  as  cons,  or  as  complicated  as 
a compiler.  All  that  enclose  guarantees  to  do  is  to  compute  a procedure 
object  given  a description  of  its  desired  behavior.  The  description  must 
be  in  the  prescribed  form;  but  the  result  may  be  in  any  form  convenient  to 
the  implementation,  as  long  as  it  satisfies  the  predicate  procp  {Note 
evaluate  Has  Disappeared)  {Note  S-expressions  Are  Not  Functions). 

As  an  example,  we  can  write  apply  using  enclose.  One  way  is  to 
generate  a lot  of  names  for  the  arguments  Involved: 

(DEFINE  APPLY 

(LAMBOA  (FN  ARGS ) 

(LET  ((VARS  (AMAPCAR  (LAMBDA  (X)  (6ENSYW))  ARGS)) 

(FNVAR  (GENSYM))) 

((ENCLOSE  -(LAMBDA  ()  (.FNVAR  VVARS ) ) 

(CONS  (CONS  FNVAR  FN) 

(AMAPCAR  CONS  VARS  ARGS))))))) 

Here  a procedure  which  will  call  the  procedure  fn  on  the  required  number  of 
arguments  is  enclosed  in  an  environment  with  all  the  variables  bound  to  the 
appropriate  values.  For  those  who  don't  like  gensym,  here  is  another  way  to 
do  it: 

(DEFINE  APPLY 

(LAMBDA  (FN  ARGS) 

(DO  ((TAIL  'A  -(COR  .TAIL)) 

(REFS  NIL  (CONS  -(CAR  .TAIL)  REFS)) 

(COUNT  ARGS  (CDR  COUNT))) 

((NULL  COUNT) 

((ENCLOSE  "(LAMBDA  (F  A)  (F  #( REVERSE  REFS)))  NIL) 

FN  ARGS))))) 

In  this  version  we  create  a series  of  forms  (car  a),  (car  (cdr  a)),  (car  (cor 
(CORA))),  ...  to  be  used  to  access  the  arguments.  (In  a way,  these  are 
distinct  names  for  the  arguments  in  the  same  way  that  the  gensyms  were  for 
the  first  version.)  The  values  fn  and  args  are  passed  in  as  arguments  to 
the  enclosed  procedure,  rather  than  giving  a non-NiL  environment 
representation  to  enclose. 

As  another  example,  we  define  a function  called  -lambda: 
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(DEFINE  ( ‘LAMBDA  VARS  BODY) 

(ENCLOSE  "(LAMBDA  .VARS  .BOOY)  NIL)) 

Writing  (‘lambda  • (x  y)  '(foo  y x))  is  Just  like  writing  (lambda  (x  y)  (foo  y x)). 
However,  if  there  are  any  free  variables  in  the  supplied  body,  then  ‘lambda 
will  cause  them  to  refer  to  the  global  environment,  not  the  current  one. 
We  cannot  in  general  simulate  lambda  by  using  ‘lambda,  because  SCHEME 
(purposefully)  does  not  provide  a general  way  to  get  a representation  of 
the  current  environment.  We  could,  of  course,  require  the  user  to  give 
•lambda  a representation  of  the  current  environment,  but  this  hardly  seems 
worthwhile. 


The  following  primitive  functions  allow  for  multiprocessing.  We  do 
not  pretend  that  they  are  "right"  in  any  sense,  and  are  not  particularly 
attached  to  these  specific  definitions.  They  are  not  part  of  the  kernel  of 
SCHEME.  (Their  primary  use  in  practice  is  for  bootstrapping  SCHEME  by 
creating  an  initial  process  for  the  top-level  user  interface  loop.) 

There  are  no  primitives  for  process  synchronization,  as  we  have  no 
good  theory  of  how  best  to  do  this.  However,  in  the  PDP-10  MacLISP 
implementation  of  SCHEME  we  guarantee  that  SUBRs  and  LSUBRs  execute  in  an 
uninterruptible  fashion;  that  is,  such  functions  can  be  considered  "atomic" 
for  synchronization  purposes.  The  user,  is  invited  to  exploit  this  fact  to 
invent  his  own  synchronization  primitives  {Note  evaluate  iuninterruptibly  Has 
Disappeared) . 


(CREATE (PROCESS  proe) 

This  is  the  process  generator  for  multiprocessing.  It  takes  one 
argument,  a procedure  of  no  arguments.  If  the  procedure  ever  terminates, 
the  entire  process  automatically  terminates.  The  value  of  create! process  is 
a process  ID  for  the  newly  generated  process.  Note  that  the  newly  created 
process  will  not  actually  run  until  it  is  explicitly  started.  When 
started,  the  procedure  will  be  invoked  (with  no  arguments),  and  the  process 
will  run  "in  parallel"  with  all  other  active  processes. 


( START (PROCESS  procld) 

This  takes  one  argument,  a process  id,  and  starts  up  or  resumes 
that  process,  which  then  runs. 


I 


~ - ’nr-''  -v-sm 


Stt«I>  «nd  Sunwin 


JL. 


Th»  Reviled  Rtport  on  SCHEME 


( STOP ! PROCESS  proeld) 

Thi?  also  takes  a process  id,  but  stops  the  process.  *The  stopped 
process  may  be  continued  from  where  it  was  stopped  by  using  startiprocess 
again  on  it.  The  global  variable  “process**  always  contains  the  process  id 
of  the  currently  running  process;  thus  a process  can  stop  itself  by  doing 
(STOPIPROCESS  “PROCESS**). 


(TERMINATE) 

This  primitive  stops  and  kills  the  process  which  invokes  it.  The 
process  may  not  be  resumed  by  t trocess.  Some  other  process  is  selected 
to  run.  If  the  last  process  is  terminated,  SCHEME  automatically  prints  a 
warning  message,  and  then  creates  a new  process  running  the  standard  SCHEME 
"read-eval-print"  (actually  "read— stick  (lambda  ()  .)  around— enclose  in  top- 
level  environment— invoke-print")  loop. 

An  example  of  the  use  of  terminate: 

(TERMINATE) 
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{Note  Notes  Are  in  Alphabetical  Order) 


{aset  Has  Disappeared) 

The  more  general  primitive  aset  described  in  [SCHEME]  has  been 
removed  from  the  SCHEME  language.  Although  the  case  of  a general  evaluated 
expression  for  the  variable  name  causes  no  real  semantic  difficulty  (it  can 
be  viewed  as  a syntactic  extension  representing  a large  case  statement,  as 
pointed  out  in  [Declarative]),  it  can  be  confusing  to  the  reader. 
Moreover,  in  two  years  we  have  not  found  a use  for  it.  Therefore  we  have 
replaced  aset  with  aset*,  which  requires  the  name  of  the  variable  to  be 
modified  to  appear  manifestly. 

We  confess  to  being  "cute"  when  we  say  that  the  name  of  the 
primitive  is  aset’ . We  have  not  changed  the  implementation  at  all,  but 
merely  require  that  the  first  argument  be  quoted.  The  form  (aset*  foo  bar) 
is  parsed  by  the  MacLISP  reader  as  (aset  (quote  foo)  bar).  Of  course,  a 
different  implementation  of  SCHEME  might  actually  take  aset1  as  a single 
name.  We  apologize  for  this  nonsense. 


{block  Exploits  Applicative  Order) 

The  definition  shown  for  block  exploits  the  applicative  order  of 
evaluation  of  SCHEME  to  perform  this  {Note  Normal  Order  Loses).  It  does 
not  depend  on  lef t-to-right  evaluation  of  arguments  to  functions!  Notice 
also  that  in 

(BLOCK  x . r)  -»  ((LAMBDA  (A  B)  (B))  X (LAMBDA  ()  (BLOCK  . r))) 

there  can  be  no  conflict  between  the  auxiliary  variables  a and  b and  any 
variables  occurring  in  x and  r.  It  is  thus  unnecessary  to  choose  variables 
different  from  any  others  appearing  in  the  code.  In  this  respect  this 
definition  is  an  improvement  over  the  one  given  in  [Imperative].  This 
trick  (which  is  actually  a deep  property  of  the  lexical  scoping  rules)  is 
used  in  a general  way  in  most  of  the  definitions  of  syntactic  extensions: 
one  wraps  all  the  "user  code"  in  lambda-expressions  in  the  outer 
environment,  passes  them  in  bound  to  internal  names,  and  then  invokes  them 
as  necessary  within  the  internal  code  for  the  definition. 
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{Environment  Symmetry) 

One  may  think  of  an  escape  object  as  being  "closed"  with  respect  to 
a dynamic  environment  (and  here  we  mean  not  only  fluid  variables  but  the 
chain  of  pending  procedure  calls)  in  much  the  same  way  that  an  ordinary 
procedure  is  closed  with  respect  to  a lexical  environment.  Just  as  a 
procedure  cannot  execute  properly  except  in  conjunction  with  a static 
environment  of  the  appropriate  form,  so  an  escape  object  cannot  properly 
resume  control  except  in  a dynamic  environment  of  the  appropriate  form. 


{evaluate  Has  Disappeared) 

The  evaluate  primitive  described  in  [SCHEME]  has  been  removed  from 
the  language.  We  discovered  (the  hard  way)  that  the  straightforward 
implementation  of  evaluate  (evaluate  the  given  expression  in  the  current 
environment)  destroys  referential  transparency.  We  then  altered  it  to 
evaluate  the  expression  in  the  top-level  environment,  but  were  still 
disturbed  by  the  extent  to  which  one  is  tied  to  a particular  representation 
of  a procedure  to  be  executed. 

We  eventually  invented  an  enclose  of  one  argument  (a  lambda- 
expression),  which  enclosed  the  procedure  in  the  top-level  environment. 
This  allowed  one  to  remove  the  dependence  on  representation  by  making  a 
procedure,  and  then  to  pass  the  procedure  around  for  a while  before 
invoking  it.  We  had  no  provision  for  closing  in  an  arbitrary  environment, 
because  we  did  not  want  to  provide  the  user  with  direct  access  to 
environments  as  data  objects.  The  excellent  idea  of  allowing  enclose  to 
accept  a representation  of  an  environment  suggested  to  us  by  R.  M. 
Fano. 


{ evaluate iuninterruptibiy  Has  Disappeared) 

The  evaluate iunjnterruptibly  primitive  described  in  [SCHEME]  has  been 
removed  from  the  language.  This  primitive  was  half  a joke,  and  we  have 
since  discovered  that  it  had  a serious  flaw  in  its  definition,  namely  that 
the  scope  of  the  uninterruptibility  is  lexical.  This  worked  in  our  limited 
examples  only  by  virtue  of  the  fact  that  SUBRs  were  atomic  operations.  In 
general,  this  primitive  is  worse  than  useless  for  synchronization  purposes. 
Synchronization  is  clearly  a dynamic  and  not  a static  phenomenon.  We  have 
no  good  theory  of  synchronization  (primitives  for  this  were  included  in 
[SCHEME]  primarily  to  show  that  it  could  be  done,  however  kludgily),  and  so 
have  defined  no  replacement  for  evaluate iuninterruptibly.  We  apologize  for  any 
confusion  this  mistake  may  have  caused. 
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(FF.XPRs  Are  Okay  by  Us} 

While  the  syntactic  extensions  are  defined  in  terms  of  other 
constructs,  they  need  not  be  implemented  in  terms  of  them.  For  example,  in 
the  current  PDP-10  MacLISP  implementation  of  SCHEME,  block  is  actually 
implemented  in  the  same  way  if  and  quote  are,  rather  than  as  a macro  in 
terms  of  lambda.  This  was  done  purely  to  speed  up  the  interpreter.  The 
compiler  still  uses  the  macro  definition  (though  we  could  change  that  too 
if  warranted).  The  point  is  that  the  user  doesn't  have  to  know  about  all 
this . 

It  is  somewhat  an  accident  that  magic  forms  look  like  procedure 
calls  (see  also  (Note  funcall  is  a Pain}):  a name  appearing  in  the  car  of  a 
list  may  represent  either  a procedure  or  a magic  word,  but  not  both.  (We 
could,  for  example,  say  that  magic  forms  are  distinguished  by  a magic  word 
in  the  cadr  of  a list,  thus  allowing  forms  such  as  (foo  :■  (■*•  foo  i)),  where 
:*  is  a magic  word  for  assignment.  PLASMA  [Smith  and  Hewitt]  allowed  just 
this  ability  with  its  "italics"  or  "reserved  word"  feature.)  Thanks  to 
this  accident  many  LISP  interpreters  store  the  magic  function  definition  in 
the  place  where  an  ordinary  procedure  definition  is  stored.  A special 
marker  (traditionally  EXPR/SUBR  or  FEXPR/FSUBR)  distinguishes  ordinary 
functions  from  magic  ones.  This  allows  the  lookup  for  a magic  word 
definition  and  an  ordinary  value  to  be  simultaneous,  thus  speeding  up  the 
implementation:  it  is  purely  an  engineering  trick  and  not  a semantic 
essence.  However,  this  trick  has  led  to  a generalization  wherein  ouote  and 
cond  are  regarded  as  functions  on  an  equal  basis  with  car  and  cons;  to  be 
sure,  they  take  their  arguments  in  a funny  way  — unevaluated  — but  they 
are  still  regarded  as  functions.  This  leads  to  all  manner  of  confusion, 
which  has  its  roots  in  a confusion  between  a procedure  and  its 
representation. 

It  is  helpful  to  consider  a simple  thought  experiment.  Let  us 
. postulate  a toy  language  called  "Number-LISP".  Programs  in  this  language 

are  written  as  s-expressions,  as  usual;  the  kernel  primitives  lambda,  if, 
labels,  etc.  are  all  present.  However,  the  primitive  functions  cons,  car, 
and  cdr  are  absent;  one  has  only  +,  *,  //,  and  -.  ouote  is  not 

available;  the  only  constants  one  can  write  are  numbers. 

, Now  Number-LISP  can  be  used  to  perform  all  kinds  of  arithmetic,  but 

it  is  clearly  a poor  language  in  which  to  write  a LISP  interpreter.  Now 
consider  the  magic  form  processors  and  syntactic  extension  functions  for 
Number-LISP.  They  are  procedures  on  s-expressions  or  functions  from  s- 
expressions  to  s-expressions  which  transform  one  form  into  another. 
Whatever  processes  if  or  labels  or  block  is  clearly  not  a Number-LISP 
procedure,  because  it  must  deal  with  the  text  of  a Number-LISP  procedure, 
not  just  the  data  to  be  operated  on  by  that  procedure.  The  iF-processor  (a 
"FEXPR" ) for  Number-LISP  must  be  coded  in  the  meta-language  for  Number- 
LISP,  whatever  that  may  be. 

Now  it  is  one  of  the  great  features  of  ordinary  LISP  that  it  can 

i serve  as  its  own  meta- language.  This  provides  great  power,  but  also 

permits  great  confusion.  If  the  implementation  allows  mixing  of  levels  of 


Steele  and  Sussman 


definition,  we  must  keep  them  separate  in  our  minds.  For  this  reason  we 
don't  mind  using  the  "FEXPR  hack"  to  implement  syntactic  forms,  but  we  do 
mind  thinking  of  them  as  functions  just  like  EXPRs. 


{ruNCALL  is  a Pain} 

The  ambiguity  between  magic  forms  and  combinations  could  be 

eliminated  by  reserving  a special  subclass  of  lists  to  represent 

combinations,  and  allowing  all  others  to  represent  magic  forms.  For 
example,  we  might  say  that  all  lists  beginning  with  the  atom  call  are 
combinations.  Then  we  would  write  (call  cons  a b)  rather  than  (cons  a »).  One 
could  then  have  a procedure  named  lambda,  for  example;  there  could  be  no 
confusion  between  (lamboa  (a)  (b  a))  and  (call  lambda  (call  a)  (call  b a)),  as  there 
would  be  between  (lambda  (a)  (b  a))  as  a combination  and  as  a magic  form 

denoting  a procedure.  Notice  that  call  is  intended  to  be  merely  a 

syntactic  marker,  like  lambda  or  if,  and  not  a function  as  funcall  is  in 
MacLISP  [Moon]. 

If  this  call  convention  were  adopted,  there  could  be  no  confusion 
between  combinations  and  other  kinds  of  forms.  Not  all  expressions  would 
have  meaningful  interpretations;  for  example  (foo  a b)  would  not  mean 
anything  (certainly  not  a call  to  the  function  foo,  which  would  be  written 
as  (call  foo  a a)).  The  space  of  meaningful  s-expresslons  would  be  a very 
sparse  subset  of  all  s-expressions,  rather  than  a dense  one.  Pt  would  also 
make  writing  SCHEME  code  very  clumsy.  (These  two  facts  are  of  course 
correlated.)  Combinations  occur  about  as  often  as  all  other  non-atomic 
forms  put  together;  we  would  like  to  write  as  little  as  possible  to  denote 
a call.  As  in  traditional  LISP,  we  agree  to  tolerate  the  ambiguity  in 
SCHEME  as  the  price  of  notational  convenience.  Indeed,  this  ambiguity  is 
sometimes  exploited;  it  is  convenient  not  to  have  to  know  whether  amapcar 
is  a function  or  a magic  word. 

This  compromise  does  lead  to  difficulties,  however.  For  example, 
we  had  wanted  to  define  an  iteration  feature: 

(LOOP  naroa  var specs  body) 

Unfortunately,  there  is  a great  deal  of  existing  code  written  in  SCHEME  of 
the  form: 

(LABELS  ((LOOP  (LAMBOA  ...  (LOOP  ...)  ...))) 

(LOOP  ...)) 

because  loop  has  become  a standard  name  for  use  in  a labels  procedure  which 
implements  an  iteration  (see,  for  example,  our  definition  of  oof).  If  loop 
were  to  become  a new  magic  word,  then  all  this  existing  code  would  no 
longer  work.  We  were  therefore  forced  to  name  it  iterate  instead  (after 
verifying  that  no  existing  code  used  the  name  iterate  for  another  purpose!). 
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There  would  have  been  no  problem  if  all  this  code  had  been  written  as: 

(LABELS  ((LOOP  (LAMBDA  ...  (CALL  LOOP  ...)  ...))) 

(CALL  LOOP  ...)) 

To  this  extent  SCHEME  has  unfortunately,  despite  our  best  Intentions, 
inherited  a certain  amount  of  referential  opacity. 


{Global  Fluid  Environment) 

There  is  a question  as  to  the  meaning  of  the  global  fluid 
environment.  In  the  PDP-10  MacLISP  implementation  of  SCHEME,  the  global 
lexical  and  fluid  environments  coincide,  but  this  was  an  arbitrary  choice 
of  convenience  influenced  by  the  structure  of  MacLISP.  We  recommend  that 
the  two  global  environments  be  kept  distinct. 


(if  Is  Data- Dependent) 

We  should  note  that  the  usefulness  of  the  definition  of  if 
explicitly  depends  on  the  particular  kinds  of  data  types  and  the  particular 
primitive  functions  available;  we  expect  to  use  if  with  primitive 
predicates  such  as  atom  and  eq.  This  is  in  contrast  to  other  kernel  forms 
such  as  lambda  and.  labels  expressions,  whose  semantics  are  independent  of  the 
data. 

We  erred  in  [SCHEME]  when  we  stated  that  a practical  interpreter 
must  have  a little  of  each  of  call-by-value  and  call-by-name  in  it.  The 
argument  was  roughly  that  a call-by-name  interpreter  must  become  call-by- 
value  when  a primitive  operator  is  to  be  applied,  and  a call-by-value 
interpreter  must  have  some  primitive  conditional  such  as  if.  We  did 
mention  the  trick  of  eliminating  if  in  a call-by-name  interpreter  by 
defining  predicates  to  return  (lambda  (x  y)  x)  for  TRUE  and  (lambda  (x  y)  y)  for 
FALSE,  whereupon  one  typically  writes: 

<(•  A B)  <do  tM*  If  TRUE)  <do  thl*  If  FALSE) ) 

but  noted  that  it  depends  critically  on  the  use  of  normal  order  evaluation. 

What  we  had  not  fully  understood  at  that  point  was  the  trick  of 
simulating  call-by-name  in  terms  of  call-by-value  by  using  lambda- 
expressions  (our  use  of  it  in  the  TRY!  TWO!  THINGS!  IN!  PARALLEL  example 
notwithstanding!);  this  trick  was  described  generally  in  [Imperative].  A 
special  case  of  this  trick  is  to  define  the  primitive  predicates  in  a call- 
by-value  interpreter  to  return  (lambda  (x  y)  (x))  for  TRUE  and  (lambda  (x  y)  ( y) > 
for  FALSE.  Then  one  can  write  things  like: 


3 


((■  A 8) 

( LAMBDA  ()  (do  tbl*  If  TRUE)) 

(LAMBDA  ()  <dc  tbl*  If  FALSE))) 

and  so  eliminate  a call-by-name-like  magic  form  such  as  if.  One  can  make 
the  dependence  of  the  conditional  on  the  primitive  data  operations  even 
more  explicit  by  defining  predicates  not  to  return  any  particular  value, 
but  to  require  two  "continuations"  as  arguments,  of  which  it  will  invoke 


(-  A B 

(LAMBDA  ()  <do  this  If  TRUE)) 

(LAMBOA  ()  <do  this  If  FALSE))) 

We  were  correct  when  we  said  that  a practical  interpreter  must  have  call- 
by-name  to  some  extent  in  that  there  must  be  some  way  to  designate  two 
pieces  of  as  yet  uninterpreted  program  text  of  which  only  one  is  to  be 
evaluated.  We  simply  did  not  notice  that  lambda  provides  this  ability,  and 

so  a separate  primitive  such  as  if  is  not  necessary.  We  have  chosen  to 

retain  if  in  the  language  because  it  is  traditional,  because  its 

implementation  is  easy  to  understand,  and  because  it  allows  us  to  take 

advantage  of  many  existing  predicates  in  the  host  language  in  the  PDP-10 
MacLISP  implementation. 


{LISP  BNF) 


These  rules  refer  to  the  following  rules  for  LISP  s-expressions : 


(atomic  symbol)  : {alphanumeric  string)  (.lattar)  {alphanumeric  string) 

{alphanumeric  string)  : {empty)  I {alphanumeric  character)  {alphanumeric  string) 

{alphanumeric  character)  {letter)  | {«*1g1t)  | / {character) 

(latter)  A | I | ...  | Y | Z | * | t | X | ... 

(digit)  0|1|?|3|4|S|6|7|8|9 
(number)  (VERY  Implementation  dependent) 

(string)  " (character  string)  * 

(•character  string)  (empty)  | (literal  character)  (character  string) 

(literal  character)  (any  character  except  * or  />  | / (character) 


(In  the  PDP-10  MacLISP  implementation  of  SCHEME,  we  use  the  " character  for 
another  purpose  because  PDP-10  MacLISP  does  not  have  a string  data  type. 
We  mention  strings  only  as  a familiar  example  other  than  numbers  of  an 
atomic  data  type  other  than  identifiers.) 

In  addition,  we  assume  the  usual  Interchangeability  of  list 
notation  and  dot  notation  for  s-expressions:  (Ate)  • (A  . (b  . (c  . ril))). 
Thus  the  pattern  ( (magic  word)  . (s-*xpr«ssi«n)  ) may  match  the  list  (cord  (a  b) 
(t  c)).  It  is  the  s-expression  representation  w*  care  about,  not  particular 
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character  strings. 


(LISP  Is  a Ball  of  Mud) 


LISP  is  extensible  in  two  ways.  First,  there  is  the  simple  ability 
to  define  new  functions;  these  are  used  in  a way  that  is  both 
syntactically  and  semantically  identical  to  built-in  primitive  functions 
like  car.  This  is  in  contrast  to  "algebraic"  programming  languages,  which 
either  make  an  arbitrary  syntactic  distinction  between  addition,  say,  and  a 
user  function,  or  wander  into  the  quagmire  of  extensible  parsers.  Second, 
there  is  a uniform  macro  facility  for  transforming  one  syntactic  form  into 
another;  this  facility  is  based  on  Internal  data  structures  rather  than 
external  character-string  syntax. 

Joel  Moses  (private  communication)  once  made  some  remarks  on  the 
difference  between  LISP  and  APL,  which  we  paraphrase  here:  "APL  is  like  a 
diamond.  It  has  a beautiful  crystal  structure;  all  of  its  parts  are 
related  in  a uniform  and  elegant  way.  But  if  you  try  to  extend  this 
structure  in  any  way  — even  by  adding  another  diamond  — you  get  an  ugly 
kludge.  LISP,  on  the  other  hand,  is  like  a ball  of  mud.  You  can  add  any 
amount  of  mud  to  it  (e.g.  MICRO-PLANNER  or  CONNIVER)  and  it  still  looks 
like  a ball  of  mud!" 


{Multiple  Throw) 

A full  implementation  of  SCHEME  allows  this  to  work  even  if  the 
CATCH  has  already  been  "returned  from";  that  is,  the  escape  object  can  be 
used  to  "return  from  the  catch*  several  times.  However,  we  allow  the 
possibility  that  an  implementation  may  allow  the  escape  object  to  be 
invoked  only  from  within  the  execution  of  the  form  inside  the  catch.  (This 
is  essentially  the  restriction  that  MacLISP  makes  on  its  catch  construct 
[Moon].)  This  restriction  permits  a stack  discipline  for  the  allocation  of 
continuations,  and  also  greatly  simplifies  the  flow  analysis  problem  for  a 
compiler  [RABBIT). 


(Normal  Order  Loses) 

Our  definition  of  block  exploits  the  fact  that  SCHEME  is  an 
applicative-order  (call-by-value)  language  in  order  to  enforce  sequencing. 
Sussman  has  proved  that  one  cannot  do  a similar  thing  in  a normal-order 
(call-by-name)  language: 
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Theorem:  Normal  order,  as  such,  is  incapable  of  enforcing  sequencing 
(whereas  applicative  order  is)  in  the  form  of  the  block  construct. 
(Informal)  proof:  The  essence  of  (block  • t>)  is  that  • is  evaluated 
before  t>,  and  that  the  value  of  b is  the  value  of  the  block  (or, 
more  correctly,  the  value  or  meaning  of  the  block  is  independent  of 
a;  a is  executed  only  for  its  side  effects).  Now  we  know  that  if 
(block  a p)  has  any  value  at  all,  it  can  be  found  by  using  normal 
order  (normal  order  terminates  if  any  order  does).  Now  suppose 
that  the  computation  of  a does  not  terminate,  but  the  computation 
of  b does.  Then  (block  a b)  must  terminate  under  normal  order, 
because  the  value  of  the  block  is  the  value  of  b;  but  this 
contradicts  the  requirement  that  a finish  before  b is  calculated. 
QED 

This  is  an  informal  indication  that  normal  order  is  less  useful  (or  at 
least  less  powerful)  in  a programming  language  than  applicative  order.  We 
also  noted  in  [SCHEME]  that  normal  order  Iterations  tend  to  consume  more 
space  that  applicative  order  iterations,  because  of  the  buildup  of  thunk 
structure.  Given  that  one  can  simulate  normal  order  in  applicative  order 
by  explicitly  creating  closures  [Imperative],  there  seems  to  be  little  to 
recommend  normal  order  over  applicative  order  in  a practical  programming 
language. 


(Notes  Are  in  Alphabetical  Order) 

The  notes  are  ordered  alphabetically  by  name,  not  in  order  of 
reference  within  the  text. 


(S-expressions  Are  Not  Functions) 

Recall  that  a lambda-expression  (i.e.  an  s-expression  whose  car  is 
the  atomic  symbol  lambda)  is  not  itself  a valid  procedure.  It  *ls  necessary 
to  enclose  it  in  order  to  Invoke  it. 

Moreover,  the  particular  representations  we  have  chosen  for 
procedures  and  environments  are  arbitrary.  In  principle,  one  could  have 
several  kinds  of  ENCLOSE,  each  transforming  instances  of  a particular 
representation  into  procedures.  For  example,  someone  might  actually  want 
to  implement  a primitive  algol -enclose,  taking  a string  and  a 2-by-N  array 
representing  code  and  environment  for  an  ALGOL  procedure: 

(ALGOL -ENCLOSE  "Integer  procedure  fect(n);  value  n;  Integer  n; 

fact  :■  If  n«0  then  1 elte  n*faet(n-l)" 

NULL-ARRAY) 
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This  could  return  a factorial  function  completely  acceptable  to  SCHEME.  Of 
course,  the  implementation  of  the  primitive  alsol-enclose  would  have  to  know 
about  the  internal  representations  of  procedures  used  by  the  Implementation 
of  SCHEME;  but  this  is  hidden  from  the  user. 

Similarly,  one  could  have  apl-enclose,  basic -enclose,  cobol -enclose, 

FORTRAN-EBCLOSE,  RPG- ENCLOSE  ... 


{Tail-Recursive  and} 

The  definition  of  and  has  three  rules,  not  only  for  the  same 
reasons  or  does,  but  because  ano  is  not  a precise  dual  to  or.  or,  on 
failure,  returns  nil,  but  and  does  not  just  return  non-NiL  on  success.  It 
must  return  the  non-NiL  thing  returned  by  its  last  form. 


(Tail-Recursive  or) 

We  might  have  defined  or  with  only  two  rules: 

(OR)  -*  'NIL 

(OR  x . r)  -*  (CORD  (x)  (T  (OR  . r))) 

. 

However,  because  of  the  way  or  Is  sometimes  used,  it  is  a technical 
convenience  to  be  able  to  guarantee  to  the  user  that  the  last  form  in  an  or 
is  evaluated  without  an  extra  "stack  frame";  that  is,  a function  called  as 
the  last  form  in  an  or  will  be  Invoked  tail-recursively.  For  example: 

(DEFINE  NOT-ALL-NIL-P 
(LAMBDA  (X) 

(LABELS  ((LOOP 

(LAMBDA  (Z) 

(OR  (CAR  Z)  (LOOP  (COR  Z) ) ) ) ) ) 

(LOOP  X)))) 

executes  iteratively  in  SCHEME,  but  would  not  execute  iteratively  If  the 
two-rule  definition  of  or  were  used. 


{What  Use  Is  It?} 

We  should  perhaps  say  Instead  that  <id«ntiri«r>  is-  treated  the  same 
as  (static  <id«ntifi«r».  The  static  construction  is  Included  in  SCHEME 
primarily  for  pedagogical  purposes,  to  provide  symmetry#  to  (fluid 
<id«ntm«r>).  The  fact  that  lone  atomic  symbols  are  Interpreted  as  lexical 
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variables  rather  than  dynamic  ones  is  in  some  sense  arbitrary.  Some 
critics  of  SCHEME  [personal  communications]  have  expressed  a certain  horror 
that  there  are  two  kinds  of  variables,  perhaps  Imagining  some  confusion  in 
the  interpretation  of  simple  identifiers.  We  can  have  as  many  kinds  of 
variables  as  we  like  (though  we  have  so  far  discovered  only  two  kinds  of 
any  great  use),  as  long  as  we  can  distinguish  them.  In  SCHEME  we 
distinguish  them  with  a special  marker,  such  as  static  or  fluid;  then,  as  a 
convenience,  we  prescribe  that  simple  atomic  symbols,  not  marked  by  such  a 
keyword,  shall  also  be  interpreted  as  lexical  variables,  because  that  is 
the  kind  we  use  most  often  in  SCHEME.  We  could  as  easily  have  defined 
simple  symbols  to  be  interpreted  as  fluid  variables,  or  for  that  matter  as 
constants  (as  numbers  and  strings  are).  We  could  also  have  prescribed  a 
different  method  of  distinguishing  types,  e.g.  "all  variables  beginning 
with  I,  J,  K,  L,  M,  or  N shall  be  fluid*.  (This  is  not  as  silly  as  it 
sounds.  A fairly  wide-spread  LISP  convention  is  to  spell  global  variables 
with  leading  and  trailing  *,  as  in  *foo*,  and  some  programmers  have  wished 
that  the  compiler  would  automatically  treat  variables  so  spelled  as 
SPECIAL.)  Indeed,  given  the  read-macro-character  facility,  we  effectively 
have  the  syntactic  rule  "all  variables  beginning  with  • shall  be  fluid". 
We  have  settled  on  the  current  definition  of  SCHEME  as  being  the  most 
convenient  both  to  implement  and  to  use. 

Compare  the  use  of  syntactic  markers  and  read-macro-characters  to 
the  constructions  <gval  x>  = ,x  » "global  value  of  x"  and  <lval  x>  = .x  ■ 
"■local  value  of  x"  in  MUDDLE  [Galley  and  Pfister].  Indeed,  in  MUDDLE  a 
simple  atomic  symbol  is  regarded  as  a constant,  not  as  an  identifier. 

All  this  suggests  another  solution  to  the  problem  posed  in  (Note 
funcail  is  a Pain)  (the  confusion  of  magic  forms  with  combinations).  The 
real  problem  is  distinguishing  a magic  word  from  a variable.  Let  us 
abbreviate  (static  foo)  to  ifoo,  just  as  (fluid  foo)  can  be  abbreviated  as  •too. 
Then  (sloop  a b)  would  have  to  be  a call  on  the  function  loop,  and  not  a 
magic  form.  Similarly,  we  could  write  (ma6ICvord  cond)  instead  of  cond,  and 
invent  an  abbreviation  for  that  too.  This  all  raises  as  many  problems  as 
it  solves  by  becoming  too  clumsy;  but  then  again,  maybe  it  isn't  asking 
too  much  to  require  the  user  to  write  all  magic  words  in  boldface  (as  in 
the  ALGOL  reference  language)  or  in  italics  (as  in  an  early  version  of 
PLASMA  [Smith  and  Hewitt])... 
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